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Abstract 

Scientific visualization can be used to produce very beautiful 
images. Frequently users and others not properly initiated into the 
mysteries of visualization research fail to appreciate the artistic 
qualities of these images. Scientists will frequently use our work to 
needlessly understand the data from which it is derived. This paper 
describes a number of effective techniques to confound such perni- 
cious activity. 
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Scientific visualization can be used to produce beautiful images. 

Users and others not properly initiated into the mysteries of visual- 
ization research fail to appreciate the artistic qualities of these 
images. Scientists will frequently use our work to needlessly under- 
stand the data from which it is derived. This paper describes a num- 
ber of effective techniques to confound such pernicious activity. 

Introduction 

Upon reading D. Bailey’s seminal work, “Twelve Ways to Fool the Masses When Giving Perfor- 
mance Results on Parallel Computers” [DHB91], the authors were struck by the brilliant simplic- 
ity of the concept. Bailey ends with the admonition "... conclude your technical presentation and 
roll the videotape. Audiences love razzle-dazzle color graphics, and this material often helps 
deflect attention from the substantive technical issues.” Unfortunately, Bailey gives no guidance 
in the means and methods to produce the intended result. The present article humbly seeks to fill 
this void. 

There are a number of time-tested scientific visualization techniques for producing pretty pictures 
while avoiding unnecessary illumination of the data. Our collection has been culled from the sci- 
entific visualization literature and numerous presentations the authors have given and attended. 

1. Never Include a Color Legend 

Many visualization techniques involve assigning colors to scalar data values. In lesser sciences, a 
legend relating colors to values is provided. In our exalted art form not only does a legend mar the 
beauty of an image, but the viewer may be diverted into idle contemplation of reality. 

Note: images can be particularly enthralling if the sequence of colors is chosen solely on aesthetic 
grounds. For optimal results, quietly use separate color mappings for different parts of the image. 

2. Avoid Annotation 

In dreary old fashioned sciences like physics and biology, investigators have been known to anno- 
tate their images with arrows pointing out features of supposed interest along with explanatory 
text. This promotes clarity of understanding, undermining the sense of awe and confusion the best 
scientific visualization engenders. 

3. Never Mention Error Characteristics 

If scientists using visualization software were aware that visualization software might introduce 
error, they might not be properly impressed by our masterworks. Therefore, never imply by word 
or deed that your algorithm introduces any numerical or algorithmic error whatsoever. After all, if 
the picture looks good it must be correct. 
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4. When in Doubt, Smooth 

Always strive for the smoothest possible surfaces since they look so much better than numerous 
ugly facets. For example, choose lighting normals to hide sharp edges in the data. Smoothing can 
also obscure errors and allow users to publish their results earlier. Both beauty and speed of publi- 
cation are more important than mere accuracy. 

5. Avoid Providing Performance Data 

When you are presenting a pretty picture, some stick-in-the-mud may ask how long it took to cal- 
culate. The fact that your ray-cast isosurface took hours of massively parallel supercomputer time 
to generate when nearly identical results could be achieved using marching cubes [LC87] in sec- 
onds on a workstation is irrelevant. In addition to being smoother (see rule 4), a ray cast image 
can include some wispy stuff scattered around to give the image an ethereal quality. 

6. Quietly Use Stop-Frame Video Techniques 

Each frame of a scientific video usually takes seconds, minutes, or even hours to produce. To 
achieve smooth animation it is usually necessary to generate video frames one at a time and trans- 
fer each separately to tape. They can then be played back at 30 or even 60 frames a second. Stop- 
frame techniques can dramatically improve perceived software performance. The magic is lost, 
however, if you are so foolish as to tell anyone what you’re doing. 

Faithful adherence to the rest of the rules will help avoid tedious debugging of software that 
already produces pretty pictures. 

7. Never Learn Anything About the Data or Scientific Discipline 

Debugging scientific visualization software is much more difficult if you are worried about pro- 
ducing correct results. Irritating details like accurate interpolation techniques get in the way; in 
many cases ad-hoc interpolation techniques can produce much prettier pictures with significantly 
less work. Better yet, programming bugs can sometimes produce stunning images. If you don’t 
know what to expect, you won’t have to find and fix such bugs. Besides, beauty is the higher truth. 

8. Never Compare Your Results with Other Visualization Techniques 

Comparison of results with other visualization techniques is fraught with danger. You may detect 
bugs in your code that will need to be fixed, a tedious chore. Much worse, other techniques may 
produce prettier pictures. 

9. Avoid Visualization Systems 

Visualization systems, such as FAST [BAN90] and AVS [UPS89], provide mechanisms to add 
modules implementing new visualization techniques. There are two problem with these systems. 
First, users may violate rule 8 to your discomfort. Second, visualization systems are usually Not 
Invented Here. 

10. Never Cite References for the Data 

If you cite a reference describing the data used to generate images, someone may read the paper 
and discover that your visualization bears no relationship to the key elements the original experi- 
ment was meant to elucidate. This will detract from your picture’s appeal and should be avoided. 


11. Claim Generality but Show Results from a Single Data Set 

It can be difficult to write visualization algorithms that function properly on a variety of data. 
Much effort may be saved by running your software on one (small) data set and using viewing 
angle and color map manipulations to make the images look different. Follow rule 10 so that no 
one will know what you’re doing. 

12. Use Viewing Angle to Hide Blemishes 

Many otherwise excellent algorithms produce 3D objects containing unsightly blemishes. Avoid 
carelessly choosing viewing angles that expose such flaws. If a suitable angle cannot be found, try 
another data set. 

13. ‘This is easily extended to 3-D’ 

3-D algorithms are almost always much more difficult than 2-D. Again, the effort of generalizing 
a promising 2-D algorithm to 3-D can detract from producing pretty pictures. To both impress 
your colleagues and avoid much tedious work, simply claim that your algorithm ‘is easily 
extended to three or more dimensions.’ Only the real pros will know you are lying, but they won’t 
challenge you since we all make identical claims. 

Conclusion 

As Dr. Bailey pointed out in [DHB91], "... it is often necessary for us to adopt some advanced 
techniques in order to deflect attention from possibly unfavorable facts.” This paper details a set 
of techniques to divert attention away from data and towards beauty. Follow these rules faithfully 
and you never need to sully your pretty pictures with the grubby realities of science. May your 
images be accepted by SIGGRAPH. 
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